src/integrations/github/api.py (1)

981-1004: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Add a pagination cap to get_issue_comments.

The while True loop has no upper bound on page/total comments fetched. A PR with an unusually large comment thread (e.g. spam or a very active discussion) will trigger many sequential GitHub API round-trips inside a single webhook-processing task, delaying check-run/comment posting and burning API rate limit. Consider capping total pages/comments and logging when the cap is hit.

♻️ Proposed fix

             session = await self._get_session()
             comments: list[dict[str, Any]] = []
             page = 1
+            max_pages = 50  # ~5000 comments; guards against pathological threads
             while True:
                 async with session.get(url, headers=headers, params={"per_page": 100, "page": page}) as response:
                     if response.status != 200:
                         ...
                     result = await response.json()
                     ...
                     page_comments = cast("list[dict[str, Any]]", result)
                     comments.extend(page_comments)
                     if len(page_comments) < 100:
                         logger.info(f"Retrieved {len(comments)} comments for issue #{issue_number} in {repo}")
                         return comments
                     page += 1
+                    if page > max_pages:
+                        logger.warning(
+                            f"Reached max_pages={max_pages} fetching comments for issue #{issue_number} in {repo}; "
+                            "results may be truncated"
+                        )
+                        return comments

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/integrations/github/api.py` around lines 981 - 1004, Update
get_issue_comments to enforce an upper bound on pagination, using a clear
maximum page or total-comment cap before continuing requests. When the cap is
reached, log that pagination was truncated and return the comments collected so
far, while preserving the existing response validation and normal completion
behavior.

src/event_processors/pull_request/processor.py (1)

355-420: 🩺 Stability & Availability | 🔵 Trivial

Local lock only serializes within one process.

The reference-counted asyncio.Lock correctly serializes concurrent async tasks within a single worker instance (verified against the concurrency test), and the GitHub comment-list check (_has_setup_awareness_comment) provides a secondary cross-process safety net. However, if this processor runs across multiple worker instances/pods, there is still a TOCTOU window between the get_issue_comments check and create_pull_request_comment across processes — two different workers could both pass the check before either posts. Worth confirming whether delivery-ID dedup upstream (per CONTRIBUTING.md) also covers "different but overlapping" events on the same PR across workers, or only identical redeliveries.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/event_processors/pull_request/processor.py` around lines 355 - 420,
Confirm whether upstream delivery-ID deduplication prevents overlapping,
distinct events for the same PR across worker instances, not only identical
redeliveries. If it does not, replace or augment the local
_setup_awareness_locks coordination in _post_rules_not_configured_comment with a
shared cross-process mechanism that atomically guards the comment existence
check and creation, while preserving the existing opened-event and
single-comment behavior.